Posted on

PyHP Database Session backend available

PyHP got the ability to save sessions on a database, the new PyHPSessionBackend config variable can be set to “db” or “file”, and PyHPDBSessionUser, PyHPDBSessionPass and PyHPDBSessionUri can be specified to set which database to use to store sessions and which user to access the database.

This works only on mysql as mysql is currently the only database supported by the pyhp database backend. Sessions will be saved in the pyhp_sessions table which will be created by pyhp itself, so remember to give to the user you choose the ability to create tables inside the selected database.

Posted on

Gluster Experience (part two)

Luckily the issue I was experiencing with gluster 2.0.0rc1 was just an ugly bug squashed in the 2.0.0rc2 release. Right now I’m keeping the configuration I blogged about and now we are thinking about topologies and expansion.

Right now the big issue is trying to provide enough bandwidth for write in replication since a single Gbit link isn’t enough. It’s too late to order infiniband so I’m stuck thinking what is the best topology given we have a single writer, 70 readers, 3 storage (gluster) and about 4 24port gigabit switches with 10Gbit expansion link unused and at least 2 gigabit interfaces per node.

More will follow soon

PS: I’m wondering how hard would be trying to get a round-robin translator to accelerate replicated writes by just issuing a write from the client node to one of the N replicating nodes and then have them sync automatically by themselves…

Posted on

About SSD drives performance

Sometime I get criticized about that, but I’m quite a massive disk space user: since I use my laptop as a desktop replacement, I always bring a lot of data with me and of course a lot of “things” (mainly accessories) that might be useful for some reasons. This make me feel quiet, but on the other hand makes my computer bag being really heavy sometimes.

Anyway, there are some situations where having a computer with you could be quite useful, but obviously you don’t want to bring all that weight all around. In the last year, lightweight “netbooks” gained a lot of hype and I considered to buy one for those occasions, just like browsing the web or checking e-mail in a weekend at seaside or something similar. In the vast (?!) universe of netbooks, about 10 days ago I chose and bought a Dell Inspiron Mini 9″ with Linux preinstalled.

After adding some packages, I quickly reduced the remaining available disk space to less than 2GB, less than my camera MMC storage! I seriously began to look for a mass storage drive replacement, and in order to spend an affordable amount I searched on eBay: in a few days I got a new Intel 16GB SSD drive connected to my new netbook.

SSDs (Solid State Drives) have the reputation to be amazingly faster that traditional hard drives, so a lot of manufacturers use them in netbooks to make them seem faster despite of their low power consumption but quite “calm” processors (like Intel Atom). However, after reinstalling and reconfiguring my Ubuntu, something seemed to be different… my netbook wasn’t reactive as before.

Was it just an impression? Was it real? To appease my curiosity, I used hdparm to benchmark my two SSD drives. The original STEC 8GB reported an uncached read speed of more than 68 MB/sec, while the Intel 16GB one only offered 37 MB/sec! The results were interesting: even if SSDs on average have smaller access times than traditional magnetic hard drives, their performances in terms of data read speed aren’t always a good bargain like lots of people think.

Since both these drives make my netbook sport an equivalent boot time (38 seconds excluding POST and Gnome user’s environment loading after login) and I won’t use it for more than chatting or browsing the web, I will stick to the slower Intel 16GB one, but it is clear that we shouldn’t rely on beliefs: SSDs aren’t all the same.

Posted on

Flash and Mac OS X bug while interrupting connections

Some days ago, testing an upload feature in a web application we’re working on, someone pointed out that something seemed to go wrong trying to interrupt an upload using Firefox on Mac OS X 10.5. That sounded quite strange, since that feature worked well on Windows and Linux on Firefox, Safari and Internet Explorer too.

To manage multimedia content uploads, we use a Flash-based plugin called SWFUpload: the main reason is to allow multiple files selection and management, since although there is a standard way to select more than one file to be sent through multipart-data forms, no browsers actually support it (or to be more correct, only latest versions of Firefox do that). After some more tests, we noticed that it wasn’t a Mozilla issue, since the problem happened on Safari too and the responsibility of the reported crash had to be assigned to the Flash Player plugin… but why that happens on Mac OS X only?

Taking a look on Google, we found out that WordPress’ uploader suffers the same problem, since it uses a Flash component as multiple file selector too… So, we weren’t the only ones in trouble!

In these cases, GDB could give quite interesting information: running this debugger attached to a Firefox process, we found that:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x15b0a000
0xffff08a0 in _memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:246
246 /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h: No such file or directory.
in /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h
(gdb) bt
#0 0xffff08a0 in _memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:246
#1 0x952966a3 in dataRead ()
#2 0x952e512d in CFReadStreamRead ()
#3 0x92269532 in HTTPNetConnection::transmitRequest ()
#4 0x92269860 in HTTPNetConnection::requestStreamCallback ()
#5 0x922673c1 in NetConnection::connectionRequest ()
#6 0x952e25a9 in _CFStreamSignalEventSynch ()
#7 0x952e4147 in CFWriteStreamSignalEvent ()
#8 0x9226fe91 in HTTPWriteFilter::streamFilterCallback ()
#9 0x92270503 in HTTPWriteFilter::_httpWrFilterStreamCallBack ()
#10 0x952e25a9 in _CFStreamSignalEventSynch ()
#11 0x952e4147 in CFWriteStreamSignalEvent ()
#12 0x92277bef in SocketStream::socketCallback ()
#13 0x92277cd1 in SocketStream::_SocketCallBack_stream ()
#14 0x952d97b1 in __CFSocketDoCallback ()
#15 0x952daf65 in __CFSocketPerformV0 ()
#16 0x952d063f in CFRunLoopRunSpecific ()
#17 0x952d0cd8 in CFRunLoopRunInMode ()
#18 0x946da2c0 in RunCurrentEventLoopInMode ()
#19 0x946da012 in ReceiveNextEventCommon ()
#20 0x946d9f4d in BlockUntilNextEventMatchingListInMode ()
#21 0x90af7d7d in _DPSNextEvent ()
#22 0x90af7630 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#23 0x90af066b in -[NSApplication run] ()
#24 0x0141ff89 in JSD_GetValueForObject ()
#25 0x012e5b21 in XRE_GetFileFromPath ()
#26 0x00cafaed in XRE_main ()
#27 0x00001d25 in start ()
Current language: auto; currently asm

WOW! Something’s triggering a failure in a part of Mac OS X’s CoreFoundation on i386 systems! And this actually fired trying to close the page while the Flash component was still uploading a file…

How to manage and correct this? On our side, the best thing we can do is trying to force the closure of pending connections using SWFUpload’s Javascript exposed methods, which effectively saves the browser from an unrelenting crash if our user clicks on the “cancel” button, but still doesn’t save from the eventuality of a less polite closure of the page.

Anyway, this highlights two facts: last version 10 of Adobe’s Flash Player still causes some problems and Apple’s transition to x86 platform has still something to be fixed.